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Foreword 



rd , 



This Technical Specification has been produced by the 3 Generation Partnership Project (3GPP). 

The contents of the present document are subject to continuing work within the TSG and may change following formal 
TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an 
identifying change of release date and an increase in version number as follows: 

Version x.y.z 

where: 

X the first digit: 

1 presented to TSG for information; 

2 presented to TSG for approval; 

3 or greater indicates TSG approved document under change control. 

y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, 
updates, etc. 

z the third digit is incremented when editorial only changes have been incorporated in the document. 
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Scope 



The present document specifies the stage 2 of the UE Positioning function of E-UTRAN, which provides the 
mechanisms to support or assist the calculation of the geographical position of a UE. UE position knowledge can be 
used, for example, in support of Radio Resource Management functions, as well as location-based services for 
operators, subscribers, and third-party service providers. The purpose of this stage 2 specification is to define the E- 
UTRAN UE Positioning architecture, functional entities and operations to support positioning methods. This 
description is confined to the E-UTRAN Access Stratum. It does not define or describe how the results of the UE 
position calculation can be utilised in the Core Network (e.g., LCS) or in E-UTRAN (e.g., RRM). 

UE Positioning may be considered as a network-provided enabling technology consisting of standardised service 
capabilities that enable the provision of location applications. The application(s) may be service provider specific. The 
description of the numerous and varied possible location applications which are enabled by this technology is outside 
the scope of the present document. However, clarifying examples of how the functionality being described may be used 
to provide specific location services may be included. 

This stage 2 specification covers the E-UTRAN positioning methods, state descriptions, and message flows to support 
UE Positioning. 
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3 Definitions and abbreviations 

3.1 Definitions 

For the purposes of the present document, the terms and definitions given in [1] apply. 

As used in this document, the suffixes '-based' and '-assisted' refer respectively to the node that is responsible for 
making the positioning calculation (and which may also provide measurements) and a node that provides measurements 
(but which does not make the positioning calculation). Thus, an operation in which measurements are provided by the 
UE to the E-SMLC to be used in the computation of a position estimate is described as 'UE-assisted' (and could also be 
called 'E-SMLC -based'), while one in which the UE computes its own position is described as 'UE-based'. 

3.2 Abbreviations 

For the purposes of the present document, the following abbreviations apply. 

AoA Angle of Arrival 

CID Cell-ID (positioning method) 

E-SMLC Enhanced Serving Mobile Location Centre 

E-CID Enhanced Cell-ID (positioning method) 

ECEF Earth-Centered, Earth-Fixed 

ECl Earth-Centered-lnertial 

EGNOS European Geostationary Navigation Overlay Service 

E-UTRAN Enhanced Universal Terrestrial Radio Access Network 

GAGAN GPS Aided Geo Augmented Navigation 

GLONASS GLObal'naya NAvigatsionnaya Sputnikovaya Sistema (Engl.: Global Navigation Satellite System) 

GMLC Gateway Mobile Location Center 

GNSS Global Navigation Satellite System 

GPS Global Positioning System 

LCS Location Services 
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LCS-AP LCS Application Protocol 

LMU Location Measurement Unit 

LP? LTE Positioning Protocol 

LPPa LTE Positioning Protocol Annex 

MO-LR Mobile Originated Location Request 

MT-LR Mobile Terminated Location Request 

NI-LR Network Induced Location Request 

PDU Protocol Data Unit 

PRS Positioning Reference Signal 

QZSS Quasi-Zenith Satellite System 

RRM Radio Resource Management 

SBAS Space Based Augmentation System 

SET SUPL Enabled Terminal 

SEP SUPL Location Platform 

SUPL Secure User Plane Location 

Tadv Timing Advance 

UE User Equipment 

WAAS Wide Area Augmentation System 

WGS-84 World Geodetic System 1984 

4 Main concepts and requirements 

4.1 Assumptions and Generalities 

The stage 1 description of LCS at the service level is provided in [3]; the stage 2 LCS functional description, including 
the LCS system architecture and message flows, is provided in [2]. 

Positioning functionality provides a means to determine the geographic position and/or velocity of the UE based on 
measuring radio signals. The position information may be requested by and reported to a client (e.g., an application) 
associated with the UE, or by a client within or attached to the core network. The position information shall be reported 
in standard formats, such as those for cell-based or geographical co-ordinates, together with the estimated errors 
(uncertainty) of the position and velocity of the UE and, if available, the positioning method (or the list of the methods) 
used to obtain the position estimate. 

Restrictions on the geographic shape encoded within the 'position information' parameter may exist for certain LCS 
client types. The EPS, including E-UTRAN, shall comply with any shape restrictions defined in LTE and, in a 
particular country, with any shape restrictions defined for a specific LCS client type in relevant national standards. For 
example, in the US, national standard J-STD-036-B restricts the geographic shape for an emergency services LCS client 
to minimally either an "ellipsoid point" or an "ellipsoid point with uncertainty circle and confidence" as defined in [4]. 

It shall be possible for the majority of the UEs (active or inactive) within a network to use the LCS feature without 
compromising the radio transmission or signalling capabilities of the E-UTRAN. 

The uncertainty of the position measurement shall be network-implementation-dependent, at the choice of the network 
operator. The uncertainty may vary between networks as well as from one area within a network to another. The 
uncertainty may be hundreds of metres in some areas and only a few metres in others. In the event that a particular 
position measurement is provided through a UE-assisted process, the uncertainty may also depend on the capabilities of 
the UE. In some jurisdictions, there is a regulatory requirement for location service accuracy that is part of an 
emergency service. Further details of the accuracy requirements can be found in [3]. 

The uncertainty of the position information is dependent on the method used, the position of the UE within the coverage 
area and the activity of the UE. Several design options of the E-UTRAN system (e.g., size of cell, adaptive antenna 
technique, pathloss estimation, timing accuracy, eNode B surveys) shall allow the network operator to choose a suitable 
and cost-effective UE positioning method for their market. 

There are many different possible uses for the positioning information. The positioning functions may be used internally 
by the EPS, by value-added network services, by the UE itself or through the network, and by "third party" services. 
The feature may also be used by an emergency service (which may be mandated or "value-added"), but the location 
service is not exclusively for emergencies. 
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The E-UTRAN is a new radio system design without a pre-existing deployment of 'legacy' UEs operating according to 
the radio interface. This freedom from legacy equipment enables the location service feature design to make use of 
appropriate techniques to provide the most accurate results. The technique must also be a cost-effective total solution, 
must allow evolution to meet evolving service requirements, and must be able to take advantage of advances in 
technology over the lifetime of E-UTRAN deployments. 

Design of the E-UTRAN positioning capability as documented in this specification includes position methods, protocols 
and procedures that are either adapted from capabilities already supported for UTRAN and GERAN, or created 
separately from first principles. The proportion of the latter is higher than if the UTRAN and GERAN capabilities had 
been designed to provide forward compatibility to other access types. In contrast to GERAN and UTRAN, the E- 
UTRAN positioning capabilities are intended to be forward compatible to other access types and other position 
methods, in an effort to reduce the amount of additional positioning support needed in the future. This goal also extends 
to user plane location solutions such as OMA SUPL ([17], [18]), for which E-UTRAN positioning capabilities are 
intended to be compatible where appropriate. 

As a basis for the operation of UE Positioning in E-UTRAN, the following assumptions apply: 

both TDD and FDD will be supported; 

the provision of the UE Positioning function in E-UTRAN and EPC is optional through support of the specified 
method(s) in the eNode B and the E-SMLC; 

UE Positioning is applicable to any target UE, whether or not the UE supports LCS, but with restrictions on the 
use of certain positioning methods depending on UE capability (as defined within the LPP protocol); 

the positioning information may be used for internal system operations to improve system performance; 

the UE Positioning architecture and functions shall include the option to accommodate several techniques of 
measurement and processing to ensure evolution to follow changing service requirements and to take advantage 
of advancing technology; 

LMU aspects are left for implementation and are not standardized in this release. 

4.2 Role of UE Positioning IVIethods 

The E-UTRAN may utilise one or more positioning methods in order to determine the position of an UE. 
Positioning the UE involves two main steps: 

signal measurements; and 

Position estimate and optional velocity computation based on the measurements. 

The signal measurements may be made by the UE or the eNode B. The basic signals measured for terrestrial position 
methods are typically the E-UTRA radio transmissions; however, other methods may make use of other transmissions 
such as general radio navigation signals including those from Global Navigation Satellites Systems (GNSSs). 

The positioning function should not be limited to a single method or measurement. That is, it should be capable of 
utilising other standard methods and measurements, as such methods and measurements are available and appropriate, 
to meet the required service needs of the location service client. This additional information could consist of readily 
available E-UTRAN measurements (FES pending RANI conclusions). 

The position estimate computation may be made by the UE or by the E-SMLC. 

4.3 Standard UE Positioning IVIethods 

The standard positioning methods supported for E-UTRAN access are: 
network-assisted GNSS methods; 
downlink positioning; 
enhanced cell ID method. 
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Hybrid positioning using multiple methods from the list of positioning methods above is also supported. 

These positioning methods may be supported in UE-based, UE-assisted/E-SMLC -based, or eNB-assisted versions. 
Table 4.3-1 indicates which of these versions are supported in this version of the specification for the standardised 
positioning methods. 

Table 4.3-1 : Supported versions of UE positioning methods 



Method 


UE-based 


UE-assisted, E-SMLC- 
based 


eNB- 
assisted 


SUPL 


A-GNSS 


Yes 


Yes 


No 


Yes (UE- 
based and 
UE-assisted 


Downlink 


Yes [FFS] 


Yes 


No 


Yes (UE- 
assisted; 
UE-based 
FFS) 


E-CID 


FFS 


Yes 


Yes 


Yes (UE- 
assisted; 

eNB- 
assisted) 



4.3.1 Network-assisted GNSS Methods 

These methods make use of UEs that are equipped with radio receivers capable of receiving GNSS signals. 

Examples of GNSS include GPS, Modernized GPS, Galileo, GLONASS, Space Based Augmentation Systems (SBAS), 
and Quasi Zenith Satelhte System (QZSS). 

In this concept, different GNSSs (e.g. GPS, Galileo, etc.) can be used separately or in combination to determine the 
location of a UE. 

The operation of the network-assisted GNSS methods is described in clause 8.1. 

4.3.2 Downlink positioning 

[FFS; downlink positioning is still under discussion in RANI] 

4.3.3 Enlnanced Cell ID Methods 

In the Cell ID (CID) positioning method, the position of an UE is estimated with the knowledge of its serving eNode B 
and cell. The information about the serving eNode B and cell may be obtained by paging, tracking area update, or other 
methods. Enhanced Cell ID (E-CID) positioning refers to techniques which use additional UE and/or E-UTRAN radio 
resource and other measurements to improve the UE location estimate. 

Although E-CID positioning may utilise some of the same measurements as the measurement control system in the 
RRC protocol, the UE generally is not expected to make additional measurements for the sole purpose of positioning; 
i.e., the positioning procedures do not supply a measurement configuration or measurement control message, and the 
UE reports the measurements that it has available rather than being required to take additional measurement actions. 

In cases with a requirement for close time coupling between UE and eNode B measurements (e.g., TADV type 1 and 
UE Tx-Rx time difference), the eNode B configures the appropriate RRC measurements and is responsible for 
maintaining the required coupling between the measurements. The operation of the Enhanced Cell ID method is 
described in clause 8.3. 



5 E-UTRAN UE Positioning Architecture 

Figure 5-1 shows the architecture in EPS applicable to positioning of a UE with E-UTRAN access. 
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The MME receives a request for some location service associated with a particular target UE from another entity (e.g., 
GMLC, eNB, or UE) or the MME itself decides to initiate some location service on behalf of a particular target UE 
(e.g., for an IMS emergency call from the UE) as described in [2]. The MME then sends a location services request to 
an E-SMLC. The E-SMLC processes the location services request which may include transferring assistance data to the 
target UE to assist with UE-based and/or UE-assisted positioning and/or may include positioning of the target UE. The 
E-SMLC then returns the result of the location service back to the MME (e.g., a position estimate for the UE and/or an 
indication of any assistance data transferred to the UE). In the case of a location service requested by an entity other 
than the MME (e.g., UE, eNB, or E-SMLC), the MME returns the location service result to this entity. 

The SLP is the SUPL entity responsible for positioning over the user plane. Further details of the relationship of the 
user -plane positioning entities to the E-UTRAN control-plane positioning architecture are described in Annex B. 





Proprietary 

interface 
possible 



LTE-Uu- 



eNode B 




Figure 5-1 : UE Positioning Architecture applicable to E-UTRAN 



5.1 UE Positioning Operations 



To support positioning of a target UE and delivery of location assistance data to a UE with E-UTRAN access in EPS, 
location related functions are distributed as shown in the architecture in Figure 5-1 and as clarified in greater detail in 
TS 23.271 [2]. The overall sequence of events applicable to the UE, E-UTRAN and E-SMLC for any location service is 
shown in Figure 5.1-1. 

Note that the UE is assumed to be in connected mode before the beginning of the flow shown in the Figure 5.1-1; that 
is, any signalling that might be required to bring the UE to connected mode prior to step la is not shown. 



£75/ 



3GPP TS 36.305 version 9.0.0 Release 9 



13 



ETSI TS 136 305 V9.0.0 (2009-10) 



UE 



eNB 



MMEl 



1a. Location Service Request 



5a. Location Servic 



1c. Location Service 
Request 



E-SMLC 



1b. Locatioi Service Request 



2. Location Services Request 



3a. eNode E 



;5b. UE Procedure;; 



4. Location 



e Response 



5c. Locatior 
Respi 



Procedures 



Service Response 



5b. Location 



Service 



onse 



EPC LCS 
Entities 



Service Response 



Figure 5.1-1 : Location Service Support by E-UTRAN 

la. Either: the UE requests some location service (e.g. positioning or delivery of assistance data) to the serving 
MME at the NAS level. 

lb. Or: some entity in the EPC (e.g. GMLC) requests some location service (e.g. positioning) for a target UE to the 
serving MME . 

Ic. Or: the serving MME for a target UE determines the need for some location service (e.g. to locate the UE for an 
emergency call). 

2. The MME transfers the location service request to an E-SMLC. 

3a. The E-SMLC instigates location procedures with the serving eNode B for the UE - e.g. to obtain positioning 
measurements or assistance data.. 

3b. In addition to step 3a or instead of step 3a, the E-SMLC instigates location procedures with the UE - e.g. to 
obtain a location estimate or positioning measurements or to transfer location assistance data to the UE. 

4. The E-SMLC provides a location service response to the MME and includes any needed results - e.g. success or 
failure indication and, if requested and obtained, a location estimate for the UE. 

5a. If step la was performed, the MME returns a location service response to the UE and includes any needed results 
- e.g. a location estimate for the UE. 

5b. If step lb was performed, the MME returns a location service response to the EPC entity in step lb and includes 
any needed results - e.g. a location estimate for the UE. 

5c. If step Ic occurred, the MME uses the location service response received in step 4 to assist the service that 
triggered this in step Ic (e.g. may provide a location estimate associated with an emergency call to a GMLC). 

Location procedures applicable to E-UTRAN occur in steps 3a and 3b in Figure 5.1-2 and are defined in greater detail 
in this specification. Steps la and 5a are also applicable to E-UTRAN support because of a capability to tunnel 
signalling applicable to steps 3a and 3b. Other steps in Figure 5.1-2 are applicable only to the EPC and are described in 
greater detail and in TS 23.271 [2]. 

Steps 3a and 3b can involve the use of different position methods to obtain location related measurements for a target 
UE and from these compute a location estimate and possibly additional information like velocity. Positioning methods 
supported in this release are summarized in clause 4.3 and described in detail in clause 8. 
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When the eNode B functions as an LCS client, it delivers the Location Service Request to the E-SMLC via the MME, 
as shown in Figure 5.1-2. 

Editor"s Note: The details of this procedure are FFS pending confirmation from SA2. 
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1 . Location Service Reque; t 



3a. eNB Procedures 



3b. UE Procedures 



5. Location Service Response 



E-SMLC 



2. Location Services Request 



4. Location Service Response 



Figure 5.1-2: Location Service Support by E-UTRAN with eNode B as Client 

1. The eNode B requests some location service (e.g. positioning) to the serving MME. 

2. The MME transfers the location service request to an E-SMLC. 

3a. The E-SMLC instigates location procedures with the serving eNode B for the UE - e.g. to obtain positioning 
measurements or assistance data. 

3b. In addition to step 3a or instead of step 3a, the E-SMLC instigates location procedures with the UE - e.g. to 
obtain a location estimate or positioning measurements or to transfer location assistance data to the UE. 

4. The E-SMLC provides a location service response to the MME and includes a location estimate for the UE. 

5. The MME returns a location service response to the eNode B and includes any needed results - e.g. a location 
estimate for the UE. 

It is FFS if handover during an LCS operation with an eNode B as the cUent requires any special handling. 

5.2 E-UTRAN Positioning Operations 

Separately from location service support for particular UEs, an E-SMLC may interact with elements in the E-UTRAN 
in order to obtain measurement information to help assist one or more position methods for all UEs. 

Editor's Note: The details of the related procedures and signalling interactions will need to await RANI completion 
of downlink and possibly uplink position method evaluation and definition. 

5.2.1 Downlink Position IVIethod Support (FFS) 

Editor"s Note: It is FFS if LPPa is used to transfer assistance data for OTDOA as opposed to relying solely on other 
methods such as OAM. If LPPa is not used for this purpose this section would not be applicable. 
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An E-SMLC can interact with any eNodeB reachable from any of the MMEs with signaling access to the E-SMLC in 
order to obtain location related information to support the downlink position method. Location related information may 
be obtained either once on demand or on a repeated and triggered basis. The information can include timing information 
for the eNodeB in relation to either absolute GNSS time or timing of other eNodeBs and information about the 
supported cells including PRS schedule. 

Signalling access between the E-SMLC and eNodeB is via any MME with signalling access to both the E-SMLC and 
eNodeB. 

5.3 Functional Description of Elements Related to UE 
Positioning in E-UTRAN 

5.3.1 User Equipment (UE) 

The UE may transmit the needed signals for uplink-based UE Positioning measurements and may make measurements 
of downlink signals from E-UTRAN and other sources such as different GNSS systems. The measurements to be made 
will be determined by the chosen positioning method. 

The UE may also contain LCS applications, or access an LCS application either through communication with a network 
accessed by the UE or through another application residing in the UE. This LCS application may include the needed 
measurement and calculation functions to determine the UE's position with or without network assistance. This is 
outside of the scope of this specification. 

The UE may also, for example, contain an independent positioning function (e.g., GPS) and thus be able to report its 
position, independent of the E-UTRAN transmissions. The UE with an independent positioning function may also make 
use of assistance information obtained from the network. 

5.3.2 Node B 

eNode B is a network element of E-UTRAN that may provide measurement results for position estimation and makes 
measurements of radio signals for a target UE and communicates these measurements to an E-SMLC. 

The eNode B may make its measurements in response to requests (e.g., from the E-SMLC), or it may autonomously 
measure and report regularly or when there are significant changes in radio conditions (e.g., changes in the E-UTRAN 
GPS timing of cell frames). 

Editor" s Note: Autonomous measurement and periodic measurement reporting by eNode B is EPS 

5.3.3 Evolved Serving IVIobile Location Centre (E-SMLC) 

The E-SMLC manages the support of different location services for target UEs, including positioning of UEs and 
delivery of assistance data to UEs. The E-SMLC may interact with the serving eNode B for a target UE in order to 
obtain position measurements for the UE, including uplink measurements made by the eNode B and downlink 
measurements made by the UE that were provided to the eNode B as part of other functions such as for support of 
handover. 

The E-SMLC may interact with a target UE in order to deliver assistance data if requested for a particular location 
service, or to obtain a location estimate if that was requested. 

For positioning of a target UE, the E-SMLC decides on the position methods to be used, based on factors that may 
include the LCS Client type, the required QoS, UE positioning capabilities, and eNode B positioning capabilities. The 
E-SMLC then invokes these positioning methods in the UE and/or serving eNode B. The positioning methods may 
yield a location estimate for UE-based position methods and/or positioning measurements for UE-assisted and network- 
based position methods. The E-SMLC may combine all the received results and determine a single location estimate for 
the target UE (hybrid positioning). Additional information like accuracy of the location estimate and velocity may also 
be determined. 
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5.3.4 Location Measurement Unit (LMU) 

LMU functionality is not included in this version of the specification. 

6 Signalling protocols and interfaces 

6.1 Network interfaces supporting positioning operations 

6.1 .1 General LCS control plane architecture 

The general LCS control plane architecture in the EPS applicable to a target UE with E-UTRAN access is defined in 

[2]. 

6.1.2 LTE-Uu interface 

The LTE-Uu interface, connecting the UE to the eNode B over the air, is used as one of several transport links for the 
LTE Positioning Protocol. 

6.1.3 SI -MME interface 

The SI -MME interface between the eNode B and the MME is transparent to all UE-positioning-related procedures. It 
is involved in these procedures only as a transport link for the LTE Positioning Protocol. 

For eNode B related positioning procedures, the SI -MME interface transports both positioning requests from the E- 
SMLC to the eNode B and positioning results from the eNode B to the E-SMLC. 

6.1.4 SLs interface 

The SLs interface, between the E-SMLC and the MME, is transparent to all UE related and eNode B related positioning 
procedures. It is then used only as a transport link for the LTE Positioning Protocols LPP and LPPa. 

The SLs interface supports location sessions instigated by the MME as defined in [2]. LPP and LPPa transport are then 
supported as part of any location session. 

6.2 UE-terminated protocols 
6.2.1 LTE Positioning Protocol (LPP) 

The LTE Positioning Protocol (LPP) is terminated between the UE and the E-SMLC. It may use either the control- or 
user -plane protocols as underlying transport. In this specification, only control plane use of LPP is defined. User plane 
support of LPP is defined in [17] and [18]. 

LPP is a point to point positioning protocol with capabilities similar to those in UMTS RRC ([15]) and GERAN RRLP 
([16]). Whereas RRLP supports positioning of a target MS accessing GERAN and RRC supports positioning of a target 
UE accessing UTRAN, LPP supports positioning and location related services (e.g. transfer of assistance data) for a 
target UE accessing E-UTRAN. To avoid creating new positioning protocols for future access types developed by 
3GPP, and to enable positioning measurements for terrestrial access types other than E-UTRAN, LPP is in principle 
forward-compatible with other access types, even though restricted to E-UTRAN access in this specification. 

LPP further supports the OMA user plane location solution SUPL 2.0, as defined in the OMA SUPL 2.0 standards 
([17], [18]), and is intended to be compatible with the successor protocols of SUPL 2.0 as well. 

LPP messages are carried as transparent PDUs across intermediate network interfaces using the appropriate protocols 
(e.g., Sl-AP over the SI -MME interface, NAS/RRC over the Uu interface). The LPP protocol is intended to enable 
positioning for LTE using a multiplicity of different position methods, while isolating the details of any particular 
positioning method and the specifics of the underlying transport from one another. 
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The protocol operates on a transaction basis between a target device and a server, with each transaction taking place as 
an independent procedure. More than one such procedure may be in progress at any given moment. An LPP procedure 
may involve a request/response pairing of messages or one or more 'unsolicited' messages. Each procedure has a single 
objective (e.g., transfer of assistance data, exchange of LPP related capabilities, or positioning of a target device 
according to some QoS and use of one or more positioning methods). Multiple procedures, in series and/or in parallel, 
can be used to achieve more complex objectives (e.g., positioning of a target device in association with transfer of 
assistance data and exchange of LPP related capabilities). Multiple procedures also enable more than one positioning 
attempt to be ongoing at the same time (e.g., to obtain a coarse location estimate with low delay while a more accurate 
location estimate is being obtained with higher delay). 

For the 3GPP EPS Control Plane solution defined in [2], the UE is the target device and the E-SMLC is the server. For 
SUPL 2.0 support, the SUPL Enabled Terminal (SET) is the target device and the SUPL Location Platform (SEP) is the 
server. The protocol does not preclude the possibility of future developments in control plane and user plane solutions 
(e.g., possible successors of SUPL 2.0, as well as possible future 3GPP control plane solutions). 

All LPP operations and procedures are defined with respect to the target and server, and thus the LPP operations and 
procedures defined here with respect to a UE and an E-SMLC can also be viewed in this more generic context by 
substituting any target for the UE and any server for the E-SMLC. 

LPP further supports multiple positioning methods as defined in section 4.3. 

LPP supports hybrid positioning, in which two or more position methods are used concurrently to provide 
measurements and/or a location estimate or estimates to the server. LPP is forward compatible with the later addition of 
other position methods in later releases (e.g., position methods associated with other types of terrestrial access). 

The operations controlled through LPP are described further in section 7.L 



6.2.2 Radio Resource Control (RRC) 

The RRC protocol is terminated between the eNode B and the UE. In addition to providing transport for LPP messages 
over the Uu interface, it supports transfer of measurements that may be used for positioning purposes through the 
existing measurement systems specified in [14]. 

6.3 eNB-terminated protocols 

6.3.1 LTE Positioning Protocol Annex (LPPa) 

The LTE Positioning Protocol Annex (LPPa) carries information between the eNode B and the E-SMLC. . It is used to 
support the following positioning functions: 

E-CID cases where assistance data or measurements are transferred from the eNode B to the E-SMLC 

data collection from eNodeBs for support of downlink OTDOA positioning (FFS) 

Editor" s Note; It is FFS whether the protocol is transparent to the MME or allows for some MME involvement in 
LPP procedures. 

6.3.2 S1 Application Protocol (S1-AP) 

The Sl-AP protocol, terminated between the MME and the eNode B, is used as transport for LPP and LPPa messages 
over the SI -MME interface. The Sl-AP protocol is also used to instigate and terminate eNode B related positioning 
procedures. 

6.4 Signalling between an E-SMLC and UE 
6.4.1 Protocol Layering 

Figure 6.4.1-1 shows the protocol layering used to support transfer of LPP messages between an E-SMLC and UE. The 
abbreviations for all protocols follow those used in [19], with the additions of LPP and LCS-AP (LCS application 
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protocol) which denotes a possible new protocol that might be functionally similar to parts of BSSAP-LE (TS 49.031), 
BSSLAP (TS 48.071) and RANAP (TS 25.413). 

Editor's Note: The protocol layering below is copied exactly from [24]. The layers below LPP on the SLs interface 
between the MME and E-SMLC are expected to be defined by CT4. Once this has occurred, the figure 
below can be updated if needed. 
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Figure 6.4.1-1 : Protocol Layering for E-SMLC to UE Signalling 

6.4.2 LPP PDU Transfer 

Figure 6.4.2-1 shows the transfer of an LPP PDU between an E-SMLC and UE, in the network- and UE-triggered cases. 
These two cases may occur separately or as parts of a single more complex operation. 
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Figure 6.4.2-1 : LPP PDU transfer between E-SMLC and UE (network- and UE-triggered cases) 

1. Steps 1 to 4 may occur before, after, or at the same time as steps 5 to 8. Steps 1 to 4 and steps 5 to 8 may also be 
repeated. Steps 1 to 4 are triggered when the E-SMLC needs to send an LPP message to the UE as part of some 
LPP positioning activity. The E-SMLC then sends an LCS-AP PDU to the MME carrying an LPP PDU 
comprising the message. 
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2. If the UE is in ECM-IDLE state, the MME performs a network triggered service request as defined in [19] in 
order to estabhsh a signalHng connection with the UE and assign a serving eNode B. 

3. The MME forwards the LPP PDU to the serving eNode B in an SI AP DownUnk NAS Transport message. The 
MME need not retain state information for this transfer; it can treat any response in step 7 as a separate non- 
associated transfer. 

4. The eNode B forwards the LPP PDU to the UE in an RRC DL Information Transfer message. 

5. Steps 5 to 8 are triggered when the UE needs to send an LPP PDU to the E-SMLC as part of some LPP 
positioning activity. If the UE is in ECM-IDLE state, the UE instigates a UE triggered service request as defined 
in [19] in order to establish a signalling connection with the MME and assign a serving eNode B. 

6. The UE sends an LPP PDU to the serving eNode B in an RRC UL Information Transfer message. 

7. The eNode B forwards the LPP PDU to the MME in an SlAP Uplink NAS Transport message. 
9. The MME forwards the LPP PDU to the E-SMLC in an LCS-AP PDU. 

6.5 Signalling between an E-SMLC and eNode B 
6.5.1 Protocol Layering 

Figure 6.5.1-1 shows the protocol layering used to support transfer of LPPa PDUs between an E-SMLC and eNode B. 

Editor's Note: the protocol layering below is adapted from [24]. The layers below LPPa on the SLs interface between 
the MME and E-SMLC are expected to be defined by CTl. Once this has occurred, the figure below can 
be updated if needed. 

Editor's Note: It is EPS if any interaction of the MME with LPPa is required. 
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Figure 6.5.1-1 : Protocol Layering for E-SMLC to eNode B Signalling 

6.5.2 LPPa PDU Transfer for UE Positioning 

Figure 6.5.2-1 shows LPPa PDU transfer between an E-SMLC and eNode B to support positioning of a particular UE. 
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Figure 6.5.2-1 : LPPa PDU Transfer between an E-SMLC and eNode B for UE Positioning 

1. Steps 1 to 3 are triggered when the E-SMLC needs to send an LPPa message to the serving eNode B for a target 
UE as part of an LPPa positioning activity. The E-SMLC then sends an LCS-AP PDU to the MME carrying an 
LPPa PDU comprising the message. 

2. If the UE is in ECM-IDLE state, the MME performs a network triggered service request as defined in TS 23.401 
[19] in order to establish a signalling connection with the UE and assign a serving eNode B. 

3. The MME forwards the LPPa PDU to the serving eNode B in an S 1 AP Downlink Location Transport message 
and includes a correlation ID related to the MME to E-SMLC location session on the SLs interface. The MME 
need not retain state information for this transfer - e.g. can treat any response in step 4 as a separate non- 
associated transfer. 

Editor"s Note: The exact transport message to be used in this step is FES. 

4. Steps 4 and 5 are triggered when a serving eNode B needs to send an LPPa message to the E-SMLC for a target 
UE as part of an LPPa positioning activity. The eNode B then sends an LPPa PDU to the MME in an SlAP 
Uplink Location Transport message and includes the correlation ID received in step 3 and the current ECGI. 

5. The MME forwards the LPPa PDU to the E-SMLC associated with the correlation ID received in step 4 in an 
LCS-AP PDU and includes the ECGI. Steps 1 to 5 may be repeated. 

Editor's Note: the above procedure will need to be reviewed after RANI has defined the downlink and any uplink 
positioning methods and after LPPa has been defined at a stage 2 level to support these methods. 

6.5.3 LPPa PDU Transfer for Positioning Support 

Editor"s Note: It is FES if LPPa is used to transfer assistance data for OTDOA as opposed to relying solely on other 
methods such as OAM. If LPPa is not used for this purpose this section would not be applicable. 

Figure 6.5.3-1 shows LPPa PDU transfer between an E-SMLC and eNode B when related to gathering data from the 
eNodeB for positioning support for all UEs. 
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Figure 6.5.3-1 : LPPa PDU Transfer between an E-SMLC and eNode B for obtaining eNodeB Data 

1 . Steps 1 and 2 are triggered when the E-SMLC needs to send an LPPa message to an eNode B to obtain data 
related to the eNodeB. The E-SMLC determines an MME with access to the eNodeB and then sends an LCS-AP 
PDU to the MME carrying an LPPa PDU and the identity of the eNodeB. 

2. The MME forwards the LPPa PDU to the identified eNode B in an SlAP DownHnk Location Transport message 
and includes the identity of the E-SMLC. The MME need not retain state information for this transfer - e.g. can 
treat any response in step 3 as a separate non-associated transfer. 

3. Steps 3 and 4 are triggered when an eNode B needs to send an LPPa PDU to an E-SMLC containing data 
applicable to the eNB. The eNode B determines an MME with access to the E-SMLC and then sends an LPPa 
PDU to the MME in an SlAP Uplink Location Transport message. The eNodeB includes the identity of the E- 
SMLC. 

4. The MME forwards the LPPa PDU to the E-SMLC indicated in step 3 in an LCS-AP PDU. Steps 1 to 4 may be 
repeated. 



7 General E-UTRAN UE Positioning procedures 

7.1 General LPP procedures for UE Positioning 



7.1.1 



LPP Procedures 



Positioning procedures in the E-UTRAN are modelled as transactions of the LPP protocol using the procedures defined 
in this specification. A procedure consists of a single operation of one of the following types: 

- Exchange of positioning capabilities; 

Transfer of assistance data; 

Transfer of location information (positioning measurements and/or position estimate). 

Parallel procedures are permitted. A single LPP message may (FES) contain information relating to more than one 
procedure (though not all combinations of procedure types are permitted; applicable restrictions on particular types of 
procedures are described in the corresponding sections). 

As described in section 6.2.1, the protocol operates between a 'target' and a 'server'. In the control-plane context, these 
entities are the UE and E-SMLC respectively; in the SUPL context they are the SET and the SLP. The terms 'target' 
and 'server' are used in the flows in this section to avoid redundancy between the two versions of the positioning 
operations. A procedure may be initiated by either the target or the server. 
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Figure 7.1.1-1: A single LPP procedure 

Figure 7.1.1-1 shows a single LPP procedure taking place immediately after session establishment. The request in step 
2 is optional. Although the figure shows the request as being originated by the server and the response by the target, the 
reverse is also possible (with some restrictions for certain procedure types). 

7.1 .2 Positioning procedure types 



7.1.2.1 



Capability exchange 



Editor's Note: It is currently assumed that a UE request for capability from E-SMLC or delivery of the E-SMLC 
capability to the UE is not supported. 

Capabilities in an LPP context refer to the ability of a target or server to support different position methods defined for 
LPP, different aspects of a particular position method (e.g. different types of assistance data for A-GNSS) and common 
features not specific to only one position method (e.g. ability to handle multiple LPP transactions) . These capabilities 
are defined within the LPP protocol and transferred between the target and the server using LPP transport. 

Editor's Note: It is FFS whether the MME may be involved in the transfer of capabilities. 

The exchange of capabilities between a target and a server may be initiated by a request or sent as 'unsolicited' 
information. If a request is used, the server sends an LPP message to the target device with a request for capability 
information. The target sends an LPP message containing a capability response. 
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Figure 7.1.2-1 : Capability transfer 

1 . Optionally, the server may send a request for the LPP related capabilities of the target. 

2. Either in response to step 1 or unilaterally, the target transfers its LPP-related capabilities to the server. The 
capabilities may refer to particular position methods or may be common to multiple position methods. 



7.1.2.2 



Assistance data transfer 



Assistance data may be transferred either by request or unsolicited. If a request is used, the target sends an LPP 
message to the server indicating the request; the server then delivers one or more LPP messages with assistance data. 

In this version of the specification, assistance data delivery is supported only via unicast transport from server to target. 
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Server 



1. LPP: Assistance data request 1 

I 2. LPP: Assistance data delivery 

I 3. LPP: Assistance data delivery 

Figure 7.1.2-2: Assistance data transfer 

1 . Optionally, the target may send a request to the server for assistance data and may indicate the particular 
assistance data needed. 

2. Either in response to step 1 or unilaterally, the server transfers assistance data to the target. The transferred 
assistance data should match any assistance data requested in step 1 if this step occurred. 

3. Optionally (e.g., if requested in step 1), the server may transfer additional assistance data to the target in one or 
more additional LPP messages. 

This procedure is unidirectional; assistance data are always delivered from the server to the target. In the event that 
multiple instances of assistance data are delivered (i.e., if step 3 occurs), the several instances are all considered as 
portions of a single procedure. 



7.1.2.3 



Location information transfer 



The term 'location information' applies both to an actual position estimate and to values used in computing position 
(e.g., radio measurements or positioning measurements). It is delivered either in response to a request or unsolicited. 



Target/Server 



Server/Target 



1 . LPP Message: Location information request - 
2. LPP Message: Location information 



3. LPP Message: Location information 



Figure 7.1.2-3: Location information transfer 

1. Optionally, the server or target (the node indicated as 'Server/Target' in Figure 7.1.2-3) may send a request for 
location information to the other node (indicated as 'Target/Server'), and may indicate the type of location 
information needed and associated QoS. 

2. Either in response to step 1 or unilaterally, the target or server ('Target/Server') transfers location information to 
the other node ('Endpoint B'). If step 1 was performed, the location information transferred should match the 
location information requested in step 1 . 

3. Optionally (e.g., if requested in step 1), the source node in step 2 may transfer additional location information to 
the recipient node in one or more additional LPP messages. 

This procedure is bidirectional at the LPP level; either the target or the server may take the role of either endpoint in 
Figure 7. 1 .2-3. Note, however, that particular constituents of the LPP messages used for this procedure may sometimes 
be sent in only one direction; e.g., while a location estimate may be valid in both directions, certain radio measurements 
may only be allowed from a target to a server. 
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7.1.2.4 



Multiple procedures 



Multiple LPP procedures may be in progress simultaneously between the same target and server nodes, to improve 
flexibility and efficiency. However, no more than one positioning procedure between a particular pair of target and 
server nodes to obtain location information shall be in progress at any time for the same position method. 

In this example, the objective is to provide the target with an estimate of its location, in a situation in which the target"s 
LPP capabilities are not known in advance to the server, and additional assistance data are required by the target. A 
message flow is shown in Figure 7.1.2.-4. 





1. LPP Message: Location information request_ 
[position estimate, transaction A] 



-2. LPP Message: Capability request [transaction B]- 



-3. LPP Message: Capability indication [transaction B]- 



-A. LPP Message: Assistance data request [transaction C]- 



-5. LPP Message: Assistance data delivery [transaction C]- 



6. LPP Message: Location information request 

[measurements, transaction D] 

-7. LPP Message: Location information [measurements, transaction D]- 



8. LPP Message: Location information_ 
[position estimate, transaction A] 



Figure 7.1.2-4: Example of multiple LPP procedures 

1. The target sends a request to the server for its geographic location and may include the required QoS. 

2. The server returns a request for the LPP related capabilities of the target. 

3. The target returns its LPP related capabilities (e.g., positioning methods supported). 

4. The target sends a request for particular assistance data. Note that step 4 could take place simultaneously with 
step 3 (i.e., using a single transport message to carry the two LPP messages; whether this concatenation would 
occur within LPP or by including multiple LPP PDUs in the transport message is a stage 3 aspect). 

5. The server returns the assistance data requested in step 4. 

6. The server sends a request for location information (e.g., for location related measurements for position methods 
supported by the target as indicated in step 3). Note that step 6 could be combined with step 5 in a single 
transport message. 

7. The target obtains and returns the location information (e.g., positioning method measurements) requested in 
step 6. 

8. The server computes a location estimate for the target, using the location information received in step 7, and 
returns this to the target, completing the procedure started in step 1 . 



7.1.2.5 



Sequence of Procedures 



LPP procedures are not required to occur in any fixed order, in order to provide greater flexibility in positioning. Thus, 
a UE may request assistance data at any time in order to comply with a previous request for location measurements 
from the E-SMLC; an E-SMLC may instigate more than one request for location information (e.g., measurements or a 
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location estimate) in case location results from a previous request were not adequate for the requested QoS; and the 
target device may transfer or request capability information to the server at any time if not already performed. 

Despite the flexibility allowed by LPP, it is expected that procedures will normally occur in the following order: 

1 . Transfer Capabilities; 

2. Transfer Assistance Data; 

3. Transfer Location information (measurements and/or location estimate). 
Specific examples for each positioning method are shown in clause 8. 

7.2 General LPPa Procedures for UE Positioning 
7.2.1 LPPa Procedures 

Positioning and data acquisition procedures between an E-SMLC and eNodeB are modelled as transactions of the LPPa 
protocol using the procedures defined in this specification. A procedure consists of a single operation of one of the 
following types: 

Transfer of location information for a particular UE (e.g. positioning measurements) 

Transfer of information applicable to the eNodeB (e.g. eNB timing differences) 

NOTE: exchange of capabilities between an eNodeB and E-SMLC and transfer of assistance data may not be 
needed (e.g. since capability information can be provisioned through O&M) 

Parallel procedures between the same E-SMLC and eNodeB are supported, with the restriction that parallel procedures 
concerning the same positioning method are not supported (the exact scope of this restriction is FES). 

For possible extensibility, the protocol is considered to operate between a generic "access node" (e.g. eNodeB) and a 
'server' (e.g. E-SMLC). A procedure may be initiated by either end. 



Access Node 



-1. LPPa Procedural Request- 
-2. LPPa Procedural Response- 



-N. LPPa Procedural Response (end transaction)- 



Server 



Figure 7.2.1-1 : A single LPPa procedure 

Figure 7.L2-1 shows a single LPPa procedure. The request in step 1 is optional. The procedure is terminated in step 2 
in the case of a UE associated procedure. For a non-UE associated procedure to gather information concerning the 
access node, additional responses may be allowed (e.g. sending of updated information periodically and/or whenever 
there is some significant change). In this case, the procedure may be ended after some additional responses. 

7.2.2 LPPa procedure types 



7.2.2.1 



Location information transfer 



The term 'location information' applies both to an actual position estimate and to values used in computing position 
(e.g., radio measurements or positioning measurements). It is delivered either in response to a request or unsolicited. 
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eNode B 



-1 . LPPa Message: Location information request- 
2. LPPa Message: Location information 



-3. LPPa Message: Location information- 



Server 



eNode B 



Server 



-1. LPPa PDU: Request Location Information- 
-2. LPPa PDU: Provide Location Information- 



-3. LPPa PDU: Provide Location Information- 



Figure 7.2.2-1 : Location information transfer 

1. The server optionally (FFS) sends a a request for location related information to the eNode B, and may indicate 
the type of location information needed and associated QoS. The server also indicates whether this refers to a 
particular UE or only to the access node. 

Editor"s Note: If the eNode B is not permitted to initiate delivery of location information, then step 1 in this 
procedure would become mandatory. 

2. Either in response to step 1 or unilaterally, the eNode B transfers location related information to the server. The 
location related information transferred should match the location related information requested in step 1 if step 
1 occurs. 

3. Optionally (e.g., if requested in step 1 if step 1 occurs), the eNode B may transfer additional location related 
information to the server in one or more additional LPPa messages. 

7.3 Service Layer Support using combined LPP and LPPa 
Procedures 

As described in [2], UE-positioning-related services can be instigated from the EPC in the case of an NI-LR or MT-LR 
location service, or from the UE in the case of an MO-LR location service. The complete sequence of operations in the 
EPC is defined in [2]. This subclause defines the overall sequences of operations that occur in the E-SMLC, E-UTRAN 
and UE as a result of the EPC operations. 

Some flows in this scenario apply only in particular situations (e.g., only when the UE is in connected mode). The 
lower-layer details of such cases are not shown in the diagrams; for instance, the process of paging a UE to bring it to 
connected mode from idle is not explicitly indicated in these diagrams. 



7.3.1 NI-LR and IVIT-LR Service Support 



Figure 7.3.1-1 shows the sequence of operations for an NI-LR or MT-LR location service, starting at the point where 
the MME initiates the service in the E-SMLC. 
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Figure 7.3.1-1 : UE Positioning Operations to support an lUIT-LR or NI-LR 

1. The MME sends a location request to the E-SMLC for a target UE and may include associated QoS. 

2. The E-SMLC may obtain location related information from the UE and/or from the serving eNode B. In the 
former case, the E-SMLC instigates one or more LPP procedures to transfer UE positioning capabilities, provide 
assistance data to the UE and/or obtain location information from the UE. The UE may also instigate one or 
more LPP procedures after the first LPP message is received from the E-SMLC (e.g., to request assistance data 
from the E-SMLC). 

3. If the E-SMLC needs location related information for the UE from the eNode B, the E-SMLC instigates one or 
more LPPa procedures. Step 3 is not necessarily serialised with step 2; if the E-SMLC and eNode B have the 
information to determine what procedures need to take place for the location service, step 3 could precede or 
overlap with step 2. 

4. The E-SMLC returns a location response to the MME with any location estimate obtained as a result of steps 2 
and 3. 

7.3.2 MO-LR Service Support 

Figure 7.3.2-1 shows the sequence of operations for an MO-LR service, starting at the point where an LCS Client in the 
UE or the user has requested some location service (e.g., retrieval of the UE's location or transfer of the UE's location to 
a third party). 



UE 



eNB 



1 . IVIO-LR Reques|t (LPP PDU) 

2. Location 



MMEl 



=!equest(LPPPDL 



E-SMLC 



LPP Procedure(s) 



4. LPPa Pro(;edure(s) 



5. Location Flesponse (LPP PDU) 
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Figure 7.3.2-1 : UE Positioning Operations to support an IVIO-LR 
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1 . The UE sends a NAS level MO-LR request to the MME. The MO-LR request may carry an LPP PDU to 
instigate one or more LPP procedures to transfer capabilities, request assistance data, request location 
information and/or transfer location information (e.g. location measurements). 

2. The MME sends a location request to the E-SMLC and includes any LPP PDU received in step 1 . 

3. The E-SMLC may obtain location related information from the UE and/or from the serving eNode B. In the 
former case or if an immediate response is needed to any LPP procedure instigated by the UE in step 1 (e.g., a 
request for assistance data), the E-SMLC instigates one or more LPP procedures to transfer UE positioning 
capabilities, provide assistance data to the UE and/or obtain location information from the UE. The UE may also 
instigate further LPP procedures after the first LPP message is received from the E-SMLC (e.g., to request 
assistance data or to request further assistance data). 

4. If the E-SMLC needs location related information for the UE from the eNode B, the E-SMLC instigates one or 
more LPPa procedures. Step 4 may also precede step 3 or occur in parallel with it. 

5. The E-SMLC returns a location response to the MME with any location estimate obtained as a result of steps 3 
and 4, and/or with a final LPP message (e.g., that could provide a location estimate to the UE if requested by the 
UE in step 1). 

6. If the UE requested location transfer to a third party the MME transfers the location received from the E-SMLC 
in step 5 to the third party as defined in [2]. 

7. The MME sends a NAS level MO-LR response to the UE, carrying any final LPP PDU that was received in step 

5. 



8 Positioning methods and Supporting Procedures 

8.1 GNSS positioning methods 
8.1.1 General 

Global Navigation Satellite System (GNSS) is the standard generic term for satellite navigation systems that provide 
autonomous geo-spatial positioning with global or regional coverage. The following GNSSs are supported in this 
version of the specification: 

GPS and its modernization [6,7,8]; 

- Galileo [9]; 

- GLONASS [10]; 

- Satellite Based Augmentation Systems (SBAS), including WAAS, EGNOS, MSAS, and GAGAN [12]; 

- Quasi-Zenith Satellite System (QZSS) [11]. 

Each global GNSS can be used individually or in combination with others. When used in combination, the effective 
number of navigation satellite signals would be increased: 

extra satellites can improve availability (of satellites at a particular location) and results in an improved ability to 
work in areas where satellite signals can be obscured, such as in urban canyons; 

extra satellites and signals can improve reliability, i.e., with extra measurements the data redundancy is 
increased, which helps identify any measurement outlier problems; 

extra satellites and signals can improve accuracy due to improved measurement geometry and improved ranging 
signals from modernized satellites. 

When GNSS is designed to inter- work with the E-UTRAN, the network assists the UE GNSS receiver to improve the 
performance in several respects. These performance improvements will: 
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reduce the UE GNSS start-up and acquisition times; the search window can be limited and the measurements 
speed up significantly; 

increase the UE GNSS sensitivity; positioning assistance messages are obtained via E-UTRAN so the UE GNSS 
receiver can operate also in low SNR situations when it is unable to demodulate GNSS satellite signals; 

allow the UE to consume less handset power than with stand-alone GNSS; this is due to rapid start-up times as 
the GNSS receiver can be in idle mode when it is not needed. 

The network-assisted GNSS methods rely on signalling between UE GNSS receivers (possibly with reduced 
complexity) and a continuously operating GNSS reference receiver network, which has clear sky visibility of the same 
GNSS constellation as the assisted UEs. Two assisted modes are supported: 

UE-Assisted: The UE performs GNSS measurements (pseudo-ranges, pseudo Doppler, etc.) and sends these 
measurements to the E-SMLC where the position calculation takes place, possibly using additional 
measurements from other (non GNSS) sources; 

UE-Based: The UE performs GNSS measurements and calculates its own location, possibly using additional 
measurements from other (non GNSS) sources. 

The assistance data content may vary depending on whether the UE operates in UE-Assisted or UE-Based mode. 

The assistance data signalled to the UE can be broadly classified into: 

data assisting the measurements: e.g. reference time, visible satellite list, satellite signal Doppler, code phase, 
Doppler and code phase search windows; 

data providing means for position calculation: e.g. reference time, reference position, satellite ephemeris, clock 
corrections. 

A UE with GNSS measurement capability may also operate in an autonomous (standalone) mode. In autonomous mode 
the UE determines its position based on signals received from GNSS without assistance from the network. 

8.1 .2 Information to be transferred between E-UTRAN Elements 

This subclause defines the information (e.g., assistance data, measurement data) that may be transferred between E- 
UTRAN elements. 



8.1.2.1 



Information that may be transferred from the E-SMLC to UE 



Table 8.1.2-1 lists assistance data for both UE-assisted and UE-based modes that may be sent from the E-SMLC to the 
UE. 

NOTE: The provision of these assistance data elements and the usage of these elements by the UE depend on the 
E-UTRAN and UE capabilities, respectively. 

Table 8.1.2-1 : Information that may be transferred from the E-SMLC to UE 



Assistance Data 



Reference Time 



Reference Location 



lonosplieric IVIodels 



Eartli Orientation Parameters 



GNSS-GNSS Time Offsets 



Differential GNSS Corrections 



Epiiemeris and Clock IVIodels 



Real-Time Integrity 



Data Bit Assistance 



Acquisition Assistance 



Almanac 



UTC Models 
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8.1.2.1.1 Reference Time 

Reference Time assistance provides the GNSS receiver with coarse or fine GNSS time information. The specific GNSS 
system times (e.g., GPS, GaHleo, Glonass system time) shall be indicated with a GNSS ID. 

In case of coarse time assistance only, the Reference Time provides an estimate of the current GNSS system time 
(where the specific GNSS is indicated by a GNSS ID). The E-SMLC should achieve an accuracy of +/- 3 seconds for 
this time including allowing for the transmission delay between E-SMLC and UE. 

In case of fine time assistance, the Reference Time provides the relation between GNSS system time (where the specific 
GNSS is indicated by a GNSS ID) and E-UTRAN air-interface timing. 

8.1.2.1.2 Reference Location 

Reference Location assistance provides the GNSS receiver with an apriori estimate of its location (e.g., obtained via 
Cell-ID, downlink positioning, etc.) together with its uncertainty. 

The geodetic reference frame shall be WGS-84, as specified in [4]. 

8.1.2.1.3 Ionospheric Models 

Ionospheric Model assistance provides the GNSS receiver with parameters to model the propagation delay of the GNSS 
signals through the ionosphere. Ionospheric Model parameters as specified by GPS [6], Galileo [9], and QZSS [11] may 
be provided. 

8.1 .2.1 .4 Earth Orientation Parameters 

Earth Orientation Parameters (EOP) assistance provides the GNSS receiver with parameters needed to construct the 
ECEF-to-ECI coordinate transformation as specified by GPS [6]. 

8.1.2.1.5 GNSS-GNSS Time Offsets 

GNSS-GNSS Time Offsets assistance provides the GNSS receiver with parameters to correlate GNSS time (where the 
specific GNSS is indicated by a GNSS-1 ID) of one GNSS with other GNSS time (where the specific GNSS is 
indicated by a GNSS-2 ID). GNSS-GNSS Time Offsets parameters as specified by GPS [6], GaUleo [9], Glonass [10], 
and QZSS [11] may be provided. 

8.1.2.1.6 Differential GNSS Corrections 

Differential GNSS Corrections assistance provides the GNSS receiver with pseudo-range and pseudo-range-rate 
corrections to reduce biases in GNSS receiver measurements as specified in [13]. The specific GNSS for which the 
corrections are valid is indicated by a GNSS-ID. 

8.1 .2.1 .7 Ephemeris and Clock Models 

Ephemeris and Clock Models assistance provides the GNSS receiver with parameters to calculate the GNSS satellite 
position and clock offsets. The various GNSSs use different model parameters and formats, and all parameter formats as 
defined by the individual GNSSs are supported by the signalling. 

8.1 .2.1 .8 Real-Time Integrity 

Real-Time Integrity assistance provides the GNSS receiver with information about the health status of a GNSS 
constellation (where the specific GNSS is indicated by a GNSS ID). 

8.1.2.1.9 Data Bit Assistance 

Data Bit Assistance provides the GNSS receiver with information about data bits or symbols transmitted by a GNSS 
satellite at a certain time (where the specific GNSS is indicated by a GNSS ID). This information may be used by the 
UE for sensitivity assistance (data wipe-off) and time recovery. 
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8.1.2.1.10 



Acquisition Assistance 



Acquisition Assistance provides the GNSS receiver with information about visible satellites, reference time, expected 
code-phase, expected Doppler, search windows (i.e., code and Doppler uncertainty) and other information of the GNSS 
signals (where the specific GNSS is indicated by a GNSS ID) to enable a fast acquisition of the GNSS signals. 



8.1.2.1.11 



Almanac 



Almanac assistance provides the GNSS receiver with parameters to calculate the coarse (long-term) GNSS satellite 
position and clock offsets. The various GNSSs use different model parameters and formats, and all parameter formats as 
defined by the individual GNSSs are supported by the signalling. 



8.1.2.1.12 



UTC Models 



UTC Models assistance provides the GNSS receiver with parameters needed to relate GNSS system time (where the 
specific GNSS is indicated by a GNSS ID) to Universal Coordinated Time. The various GNSSs use different model 
parameters and formats, and all parameter formats as defined by the individual GNSSs are supported by the signalling. 

8.1 .2.2 Information that may be transferred from the UE to E-SMLC 

The information that may be signalled from UE to the E-SMLC is listed in table 8.1.2-2. 

Table 8.1.2-2: Information that may be transferred from UE to the E-SMLC 



Information 


UE-assisted 


UE-based/ 
standalone 


Latitude/Longitude/Altitude, together with uncertainty shape 


No 


Yes 


Velocity, together with uncertainty shape 


No 


Yes 


Reference Time, possibly together with GNSS-E-UTRAN 
time association and uncertainty 


Yes 


Yes 


Indication of used positioning methods in the fix 


No 


Yes 


Code phase measurements 


Yes 


No 


Doppler measurements 


Yes 


No 


Carrier phase measurements 


Yes 


No 


Measurement quality parameters for each measurement 


Yes 


No 


Additional, non-GNSS related measurement information 


Yes 


No 



8.1.2.2.1 



GNSS Measurement Information 



The GNSS measurement information reported from the UE to the E-SMLC depends on the GNSS mode (i.e., UE-based, 
autonomous (standalone), or UE-assisted). 



8.1.2.2.1.1 



UE-based mode 



In UE-based or standalone mode, the GNSS receiver reports the latitude, longitude and possibly altitude, together with 
an estimate of the location uncertainty, if available. 

If requested by the E-SMLC and supported by the UE, the GNSS receiver may report its velocity, possibly together 
with an estimate of the uncertainty, if available. 

If requested by the E-SMLC and supported by the UE, the GNSS receiver may report the relation between GNSS 
system time (where the specific GNSS is indicated by a GNSS ID; the specific GNSS system time may be selected by 
the UE) and E-UTRAN air-interface timing. This information may be used by the E-SMLC to assist other UEs in the 
network. 

The UE should also report an indication of which GNSSs and possibly other location methods have been used to 
calculate a fix. 
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8.1.2.2.1.2 



UE-assisted mode 



In UE-assisted mode, the GNSS receiver reports the Code Phase and Doppler measurements together with associated 
quality estimates. These measurements enable the E-SMLC to calculate the location of the UE, possibly using other 
measurements and data. 

If requested by the E-SMLC and supported by the UE, the GNSS receiver may report Carrier Phase measurements 
together with associated quality measurements, if available. 

If requested by the E-SMLC and supported by the UE, the GNSS receiver may report the relation between GNSS 
system time (where the specific GNSS is indicated by a GNSS ID; the specific GNSS system time may be selected by 
the UE) and E-UTRAN air-interface timing. This information may be used by the E-SMLC to assist other UEs in the 
network. 



8.1.2.2.2 



Additional Non-GNSS Related Information 



Additional non-GNSS measurements performed by E-UTRAN or UE may be used by the E-SMLC or UE to calculate 
or verify a location estimate. This information may include downlink positioning measurements, pathloss and signal 
strength related measurements, etc. 

8.1.3 Assisted-GNSS Positioning Procedures 
8.1 .3.1 Position Capability Transfer Procedure 

The purpose of this procedure is to enable the E-SMLC to obtain the positioning capabilities of the UE. 



8.1.3.1.1 



E-SMLC-initiated (UE to E-SMLC) Position Capability Transfer 



Figure 8.1.3-1 shows the Position Capability Transfer operations for the network-assisted GNSS method when position 
capabilities are transferred from the UE to the E-SMLC. 



UE 



E-SMLC 



-1 . LPP Message (Type: Request Capabilities)- 



-2. LPP Message (Type: Provide Capabilities)- 



Figure 8.1.3-2: E-SMLC-initiated Position Capability Transfer 

(1) Optionally, the E-SMLC determines that the positioning capabilities of the UE are needed and sends an LPP 
message to the UE including a Request Capabilities type. The request indicates that the A-GNSS capabilities of 
the UE are needed and may indicate a request for the capabilities of other position methods also. 

(2) When the UE has received an LPP message of type Request Capabilities that includes a request for A-GNSS 
capabilities or unilaterally in the absence of step 1, the UE sends an LPP message of type Provide Capabilities to 
the E-SMLC. This message includes the A-GNSS positioning capabilities of the UE, including the GNSSs and 
signals per GNSS supported, GNSS modes supported, A-GNSS associated hybrid mode combinations supported. 
The LPP message may also indicate the UE support for specific GNSS measurements, such as carrier phase 
measurements, velocity, or fine time assistance measurements and may include the types of assistance data 
supported by the UE. If step 1 occurred and the UE cannot fulfill the request, a LPP message of type Error is sent 
instead, providing the specific error reason. 
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8.1.3.2 



Assistance Data Delivery Procedure 



The purpose of this procedure is to enable the E-SMLC to provide assistance data to the UE (e.g., as part of a 
positioning procedure) and the UE to request assistance data from the E-SMLC (e.g., as part of a positioning procedure 
or for autonomous self location (i.e., UE determines its own location)). 



8.1.3.2.1 



E-SMLC initiated Assistance Data Delivery 



Figure 8.1.3-5 shows the Assistance Data Delivery operations for the network-assisted GNSS method when the 
procedure is initiated by the E-SMLC. 



E-SMLC 



(1) 



UE 



LPP Message(Type: Provide Assistance Data) 



Figure 8.1.3-6: E-SMLC-initiated Assistance Data Delivery Procedure 

(1) The E-SMLC determines that assistance data needs to be provided to the UE (e.g., as part of a positioning 

procedure) and sends an LPP message of type Provide Assistance Data to the UE. This PDU may include any of 
the GNSS assistance data defined in subclause 8.1.2.1. The entire set of assistance data maybe delivered in one 
or several LPP messages, e.g., one message per GNSS. In this case, this step may be repeated by the E-SMLC 
several times. 



8.1.3.2.2 



UE initiated Assistance Data Delivery 



Figure 8.1.3-7 shows the Assistance Data Delivery operations for the network-assisted GNSS method when the 
procedure is initiated by the UE. 



UE 



E-SMLC 



-1 . LPP Message (Type: Request Assistance Data)- 
-2. LPP Message (Type: Provide Assistance Data)- 



Figure 8.1.3-8: UE-initiated Assistance Data Delivery Procedure 

(1) The UE determines that certain A-GNSS assistance data are desired (e.g., in case the UE requires its own 
location with autonomous self location or as part of a positioning procedure when the E-SMLC provided 
assistance data are not sufficient for the UE to fulfill the request) and sends a LPP message of type Request 
Assistance Data to the E-SMLC. This request includes an indication of which specific A-GNSS assistance data 
are requested for each GNSS, possibly together with additional information (e.g., for which GNSS signal types, 
or satellites, or times the assistance is requested, etc.). Additional information concerning the UE's approximate 
location and serving and neighbour cells may also be provided in the Request Assistance Data message and/or in 
an accompanying Provide Location Information message to help the E-SMLC provide appropriate assistance 
data. This additional data may include the UE's last known location if available, the cell IDs of the UE serving 
eNodeB and possibly neighbour eNodeBs, as well as E-CID measurements. 

(2) The E-SMLC provides the requested assistance in a LPP message of type Provide Assistance Data, if available at 
the E-SMLC. The entire set of assistance data may be delivered in one or several LPP messages, e.g., one 
message per GNSS. In this case, this step may be repeated by the E-SMLC several times. If any of the UE 
requested assistance data in step (1) are not provided in step 2, the UE shall assume that the requested assistance 
data are not supported, or currently not available at the E-SMLC. If none of the UE requested assistance data in 
step (1) can be provided by the E-SMLC, an LPP message of type Error is sent by the E-SMLC instead, 
providing the error reason. 
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8.1.3.3 



Position Measurement Procedure 



The purpose of this procedure is to enable the E-SMLC to request position measurements or location estimate from the 
UE, or to enable the UE to provide location measurements to the E-SMLC for position calculation (e.g., in case of basic 
self location where the UE requests its own location). 



8.1.3.3.1 



E-SMLC initiated Position Measurement 



Figure 8.1.3-9 shows the Position Measurement operations for the network-assisted GNSS method when the procedure 
is initiated by the E-SMLC. 



UE 



E-SMLC 



-1 . LPP Message (Type: Request Location Information)- 
-2. LPP Message (Type: Provide Location Information)- 



Figure 8.1.3-10: E-SMLC-initiated Position IVIeasurement Procedure 

(1) Optionally, the E-SMLC sends a LPP message of type Request Location Information to the UE for invocation of 
A-GNSS positioning. This request includes positioning instructions such as the GNSS mode (UE-assisted, UE- 
based, UE-based preferred but UE-assisted allowed, UE-assisted preferred, but UE-based allowed, standalone), 
positioning methods (GPS, Galileo, Glonass, etc. and possibly non-GNSS methods, such as downlink 
positioning or E-CID), specific UE measurements requested if any, such as fine time assistance measurements, 
velocity, carrier phase, multi-frequency measurements, and quality of service parameters (accuracy, response 
time). 

(2) If step 1 occurred, the UE performs the requested measurements and possibly calculates its own location. 
Alternatively, if step 1 did not occur, the UE may initiate step 2 and obtain measurements in the absence of a 
request - e.g. to provide to the E-SMLC in association with the procedure in Figure 8.1.3-12. The UE sends an 
LPP message of type Provide Location Information to the E-SMLC before the Response Time provided in step 
(1) elapsed if step 1 occurred. If step 1 occurred and the UE is unable to perform the requested measurements, or 
if the Response Time provided in step 1 elapsed before any of the requested measurements have been obtained, 
the UE sends a LPP message of type Error instead, providing the error reason. 



8.1.3.3.2 



UE-initiated Position Measurement 



Figure 8. 1.3- 11 shows the Position Measurement operations for the network-assisted GNSS method when the procedure 
is initiated by the UE. This procedure may be used by the UE in case of basic self location for UE-assisted mode (i.e., 
UE requests its own location). 

Editor"s note: This figure is not entirely aligned with the generic flow shown in section 5.1 regarding the triggering 
of the location operation. The details of the flow are FFS and some coordination with other groups is 
required to converge on upper-layer aspects. 



UE 



E-SMLC 



1. LPP IMessage (Type: Request Location Information, _ 
Type: Provide Location information) 

-2. LPP Message (Type: Provide Location information)- 



Figure 8.1.3-12: UE-initiated Position IVIeasurement Procedure (Basic Self Location) 

(1) The UE sends a LPP message of type Request Location Information to the E-SMLC, including preferred location 
methods and quality of service parameters (accuracy and response time). The UE may also include an associated 
Provide Location Information message as described in step 2 of Figure 8.1.3-10 containing A-GNSS and 
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possibly other measurements. The Provide Location Information type may include any UE measurements 
(GNSS pseudo-ranges, and other measurements) already available at the UE and supported by the E-SMLC. 

(2) If the E-SMLC is able to calculate the UE position and velocity (if requested), it returns the location and velocity 
(possibly together with uncertainty information) to the UE in a LPP message of type Provide Location 
Information. If the E-SMLC cannot obtain the UE location, a LPP message of type Error is sent instead, 
providing the specific error reason. 



8.2 Downlink positioning method 



Editor's Note: Downlink positioning is still under discussion in RANL This section is based on the available 
information at the time of writing, but the contents cannot be considered definitive until RAN 1 have 
concluded. 

8.2.1 General 

In the downlink positioning method, the UE positiong is estimated based on measurements taken at the UE of downlink 
radio signals from multiple eNode Bs, along with knowledge of the geographical coordinates of the measured eNode Bs 
and their relative downlink timing. 

The specific positioning techniques used to estimate the UE"s location from this information are beyond the scope of 
this specification. 

8.2.2 Information to be transferred between E-UTRAN Elements 

This subclause defines the information that may be transferred between E-UTRAN elements. 

8.2.2.1 Assistance Data that may be transferred from the E-SMLC to UE 

The following assistance data may be transferred from the E-SMLC to the UE: 

Physical cell IDs (PCIs) and global cell IDs (GCIs) of candidate cells for measurement; 

Timing relative to the serving eNode B of candidate cells; 

Geographical coordinates of candidates cells and/or of the serving eNode B. 

Some assistance data are needed only for certain forms of a downlink positioning procedure (e.g., for UE-based only). 
Editor's Note: It is FFS if UE-based downlink positioning is supported in this version of the specification. 

8.2.2.2 Assistance Data that may be transferred from the eNode B to E-SMLC 

The following assistance data may be transferred from the eNode B to the E-SMLC: 

PCI and GCI of the cells under the eNode B and/or of cells under other eNode Bs; 

Timing information on the eNode B and/or of other eNode Bs; 

Geographical candidates of the eNode B and/or of other eNode Bs. 

An eNode B may provide assistance data relating only to itself, or it may supply the E-SMLC with assistance data 
relating to several eNode Bs (e.g., relative timing information). 

NOTE: The assistance data described in this section are not necessarily transferred only from the eNode B, and in some 
deployment options may not be delivered from the eNode B at all; they may also be delivered to the E-SMLC through 
OA&M or other mechanisms external to the E-UTRAN. In addition, in cases where assistance data are delivered from 
the eNode B, how the eNode B acquires the data is outside the scope of this specification. 
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8.2.2.3 



Location Information that may be transferred from the UE to E-SMLC 



The information that may be signalled from UE to the E-SMLC is listed in Table 8.2.2-1. The individual UE 
measurements are defined in [20, 21]. 

Table 8.2.2-1 : Information that may be transferred from UE to the E-SMLC 



Information 


Measurements 


Downlink Measurement Results List for 
EUTRA 


Physical cell IDs 


Global cell IDs 


Downlink timing measurements 



Editor's Note: The details of the measurements are FFS. 

8.2.3 Downlink Positioning Procedures 

The procedures described in this subclause support downlink positioning measurements obtained by the UE and 
provided to the E-SMLC using LPP, or obtained by the eNode B and provided to the E-SMLC using LPPa. 

Editor's Note: This section describes only UE-assisted downlink positioning. 

8.2.3.1 Position Capability Transfer Procedure 

The purpose of this procedure is to enable the E-SMLC to obtain the positioning capabilities of the UE. 



8.2.3.1.1 



E-SMLC-initiated Position Capability Transfer 



Figure 8.2.3-1 shows the Position Capability Transfer operations for the downlink method when the request for the 
position capabilities is initiated by the E-SMLC. 



UE 



E-SMLC 



-1 . LPP Message (Type: Request Capabilities)- 
-2. LPP Message (Type: Provide Capabilities)- 



Flgure 8.2.3-1: E-SMLC-initiated Position Capability Transfer 

(1) Optionally, the E-SMLC determines that the positioning capabilities of the UE are needed and sends an LPP 
message to the UE including a Request Capabilities type. The request indicates that the downlink positioning 
capabilities of the UE are needed and may include a request for the capabilities of other position methods as 
well. 

(2) If step 1 occurs, or if the UE determines to send its capabilities to the E-SMLC in an unsolicited manner, the UE 
sends an LPP message of type Provide Capabilities to the E-SMLC. This message shall include the positioning 
capabilities of the UE requested in step 1 (or determined by the UE in the absence of step 1), including the 
measurements supported for downlink positioning. 

8.2.3.2 Assistance Data Delivery Procedure 

8.2.3.2.1 Assistance Data Delivery between E-SMLC and UE 

The purpose of this procedure is to enable the E-SMLC to provide assistance data to the UE (e.g., as part of a 
positioning procedure) and the UE to request assistance data from the E-SMLC (e.g., as part of a positioning procedure 
or for autonomous self location (i.e., UE determines its own location)). 
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8.2.3.2.1.1 



E-SMLC-initiated assistance data delivery to tine UE 



Figure 8.2.3-3 shows the Assistance Data Delivery operations for the network downhnk positioning method when the 
procedure is initiated by the E-SMLC. 



UE 



E-SMLC 



-1 . LPP Message (Type: Provide Assistance Data)- 



Figure 8.2.3-3: E-SMLC-initiated Assistance Data Delivery Procedure 



(l)The E-SMLC determines that assistance data needs to be provided to the UE (e.g., as part of a positioning 

procedure) and sends an LPP message of type Provide Assistance Data to the UE. This message may include any 
of the downlink positioning assistance data defined in subclause 8.2.2.1. 



8.2.3.2.1.2 



UE-initiated assistance data delivery to the UE 



Figure 8.2.3-4 shows the Assistance Data Delivery operations for the downlink positioning method when the procedure 
is initiated by the UE. 



UE 



E-SMLC 



-1 . LPP Message (Type: Request Assistance Data)- 
-2. LPP Message (Type: Provide Assistance Data)- 



Figure 8.2.3-4: UE-initiated Assistance Data Delivery Procedure 

(l)The UE determines that certain downlink positioning assistance data are desired (e.g., in case the UE requires its 
own location with autonomous self location, or as part of a positioning procedure when the E-SMLC -provided 
assistance data are not sufficient for the UE to fulfill the request) and sends an LPP message of type Request 
Assistance Data to the E-SMLC. This request includes an indication of which specific downlink assistance data 
are requested. Additional information concerning the UE's approximate location and serving and neighbour cells 
may also be provided in the Request Assistance Data message and/or in an accompanying Provide Location 
Information message to help the E-SMLC provide appropriate assistance data. This additional data may include 
the UE's last known location if available, the cell IDs of the UE serving eNodeB and possibly neighbour 
eNodeBs, as well as E-CID measurements. 

(2) The E-SMLC provides the requested assistance in an LPP message of type Provide Assistance Data, if available 
at the E-SMLC. If any of the UE requested assistance data in step (1) are not provided in step 2, the UE shall 
assume that the requested assistance data are not supported, or currently not available at the E-SMLC. If none of 
the UE requested assistance data in step (1) can be provided by the E-SMLC, an LPP message of type Error is 
sent by the E-SMLC instead, providing the error reason. 



8.2.3.2.2 



Assistance Data Delivery between E-SMLC and eNode B 



Editor"s Note: It is FFS if LPPa is used to transfer assistance data for OTDOA as opposed to relying solely on other 
methods such as OAM. If LPPa is not used for this purpose this section would not be applicable. 

The purpose of this procedure is to enable the eNode B to provide assistance data to the E-SMLC, for subsequent 
delivery to the UE using the procedures of subclause 8.2.3.2.1 or for use in the calculation of positioning estimates at 
the E-SMLC. 
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8.2.3.2.2.1 



eNode B-initiated assistance data delivery to the E-SMLC 



Figure 8.2.3-5 shows the Assistance Data DeUvery operation from the eNode B to the E-SMLC for the network 
downlink positioning method, in the case where the procedure is initiated by the eNode B. 



eNode B 


LPPa Message(Type: Provide Assistance Data) 


E-SIVILC 


(1) 




^ 













Figure 8.2.3-5: E-SMLC-initiated Assistance Data Delivery Procedure 

(l)The eNode B determines that assistance data need to be provided to the E-SMLC (e.g., as part of a periodic 
update or in response to a change in assistance data) and sends an LPPa message of type Provide Assistance Data 
to the E-SMLC. This message may include any of the downlink positioning assistance data defined in subclause 
8.2.2.L 



8.2.3.2.2.2 



E-SMLC-initiated assistance data delivery to the E-SMLC 



Figure 8.2.3-6 shows the Assistance Data Delivery operation from the eNode B to the E-SMLC for the downlink 
positioning method, in the case that the procedure is initiated by the E-SMLC. 



eNode B 


LPPa Message(Type: Request Assistance Data) 


E-SIVILC 


(1) 
(2) 










LPPa IVIessageCType: Provide Assistance Data) 















Figure 8.2.3-6: E-SMLC-initiated Assistance Data Delivery Procedure 

(1) The E-SMLC determines that certain downlink positioning assistance data are desired (e.g., as part of a periodic 
update or as triggered by OAM) and sends an LPPa message of type Request Assistance Data to the eNode B. 
This request includes an indication of which specific downlink assistance data are requested. 

(2) The eNode B provides the requested assistance in an LPPa message of type Provide Assistance Data, if available 
at the eNode B. If the requested assistance data in step (1) are not provided in step 2, an LPPa message of type 
Error is sent by the eNode B instead, providing the error reason. 



8.2.3.3 



Position Measurement Procedure 



The purpose of this procedure is to enable the E-SMLC to request position measurements from the UE, or to enable the 
UE to provide location measurements to the E-SMLC for position calculation (e.g., in case of basic self location where 
the UE requests its own location). 



8.2.3.3.1 



E-SMLC-initiated Position Measurement 



Figure 8.2.3-7 shows the Position Measurement operations for the downlink positioning method when the procedure is 
initiated by the E-SMLC. 
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UE 



E-SMLC 



-1 . LPP Message (Type: Request Location Information)- 
-2. LPP Message (Type: Provide Location Information)- 



Figure 8.2.3-7: E-SMLC-initiated Position IVIeasurement Procedure 

(1) Optionally, the E-SMLC sends an LPP message of type Request Location Information to the UE. This request 
includes indication of downlink measurements requested, including any needed measurement configuration 
information, and required response time. 

(2) If step 1 occurs, or if the UE determines to provide unsolicited downlink measurements to the E-SMLC (e.g. as 
part of the procedure in Figure 8.2.3-8), the UE obtains downlink measurements as requested in step 1, or as 
determined by the UE in the absence of step 1 . The UE then sends an LPP message of type Provide Location 
Information to the E-SMLC, before the Response Time provided in step (1) elapsed if step 1 occurred, and 
includes the obtained downlink measurements. If step 1 occurred and if the UE is unable to perform the 
requested measurements, or the Response Time elapsed before any of the requested measurements were 
obtained, the UE sends an LPP message of type Error instead, providing the error reason. 



8.2.3.3.2 



UE-initiated Position Measurement 



Figure 8.2.3-8 shows the Position Measurement operations for the downlink positioning method when the procedure is 
initiated by the UE. This procedure may be used by the UE in case of basic self location (i.e., UE requests its own 
location). 



UE 



E-SMLC 



1. LPP Message (Type: Request Location lnformation,_ 
Type: Provide Location Information) 

-2. LPP Message (Type: Provide Location Infornnation)- 



Figure 8.2.3-8: UE-initiated Position IVIeasurement Procedure (Basic Self Location) 

(1) The UE sends an LPP message of type Request Location Information to the E-SMLC, including preferred 
location methods and quality of service parameters (accuracy and response time). The UE may also include a 
Provide Location Information type, as described in step 2 of Figure 8.2.3-7, containing downlink positioning 
(and possibly other) measurements . The Provide Location Information type may include any UE downlink 
measurements already available at the UE and supported by the E-SMLC. 

(2) If the E-SMLC is able to calculate the position, it returns the location (possibly together with uncertainty 
information) to the UE in an LPP message of type Provide Location Information. If the E-SMLC can not obtain 
the UE location, an LPP message of type Error is sent instead, providing the specific error reason. 

8.3 Enhanced cell ID positioning methods 
8.3.1 General 

In the Cell ID (CID)-based method, the UE position is estimated with the knowledge of the geographical coordinates of 
its serving eNodeB. Enhanced Cell ID (E-CID) positioning refers to techniques which use additional UE and/or 
E-UTRAN radio resource related measurements to improve the UE location estimate. For E-UTRAN access, these 
measurements may include [20, 21]: 

UE measurements ([20], [21]): 

- E-UTRA carrier RSSI; 
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Reference signal received power (RSRP); 

Reference Signal Received Quality (RSRQ); 

UE Rx - Tx time difference. 

E-UTRAN measurements ([20], [21]): 

eNB Rx - Tx time difference 

Timing Advance (Tadv): 

Typel: Tadv = (eNB Rx - Tx time difference) + (UE Rx - Tx time difference) 

Type2: T^dv = eNB Rx - Tx time difference; 

- Angle of Arrival (AoA). 

Various techniques exist to use these measurements to estimate the location of the UE. The specific techniques are 
beyond the scope of this specification. 

8.3.2 Information to be transferred between E-UTRAN Elements 

This subclause defines the information (e.g., measurement data) that may be transferred between E-UTRAN elements. 

8.3.2.1 Information that may be transferred from the E-SMLC to UE 

UE-assisted Enhanced Cell-ID location does not require any assistance data to be transferred from the E-SMLC to the 
UE. 

UE-Based Enhanced Cell-ID location is PES. 

8.3.2.2 Information that may be transferred from the UE to E-SMLC 

The information that may be signalled from UE to the E-SMLC is listed in table 8.3.2-2. 

Table 8.3.2-2: Information that may be transferred from UE to the E-SMLC 



Information 


UE-assisted 


UE-based 
[FFS] 


Latitude/Longitude/Altitude, together with uncertainty shape 


No 


FFS 


Evolved Cell Global Identifier (ECGI)/Physical Cell ID 


Yes 


No 


E-UTRA carrier RSSI 


Yes 


No 


Reference signal received power (RSRP) 


Yes 


No 


Reference Signal Received Quality (RSRQ) 


Yes 


No 


UE Rx - Tx time difference 


Yes 


No 



8.3.2.3 Information that may be transferred from the eNB to E-SMLC 

The information that may be signalled from eNB to the E-SMLC is listed in table 8.3.2-3. 

Table 8.3.2-3: Information that may be transferred from eNB to the E-SMLC 



Information 



Timing Advance (Tadv) 



Angle of Arrival (AoA) 



E-UTRA Measurement Results List: 



- Evolved Cell Global Identifier (ECGI)/Physical Cell ID 



- E-UTRA carrier RSSI (FFS) 



Reference signal received power (RSRP) (FFS) 



- Reference Signal Received Quality (RSRQ) (FFS) 
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8.3.3 Downlink E-CID Positioning Procedures 

The procedures described in this subclause support E-CID related measurements obtained by the UE and provided to 
the E-SMLC using LPP. The term 'downlink' is intended to indicate that from the E-SMLC perspective the involved 
measurements are provided by the UE; this set of procedures might also be considered as 'UE-assisted, E-SMLC -based 
E-CID'. 

It is FFS if UE-basedE-CID positioning will be supported in this version of the specification. 

8.3.3.1 Position Capability Transfer Procedure 

The purpose of this procedure is to enable the E-SMLC to obtain the positioning capabilities of the UE. 



8.3.3.1.1 



E-SMLC-initiated (UE to E-SMLC) Position Capability Transfer 



Figure 8.3.3-1 shows the Position Capability Transfer operations for the E-CID method when position capabilities are 
transferred from the UE to the E-SMLC. 



UE 


LPP Message(Type: Request Capabilities) 


E-SMLC 


(1) 
(2) 


^ 








LPP IVIessageCType: Provide Capabilities) 















Figure 8.3.3-1 : E-SMLC-initiated Position Capability Transfer. 

(1) Optionally, the E-SMLC determines that the positioning capabilities of the UE are needed and sends a LPP 
message to the UE including a Request Capabilities type. The request indicates that the E-CID capabilities of the 
UE are needed and may indicate a request for the capabilities of other position methods also. 

(2) When the UE has received an LPP message of type Request Capabilities that includes a request for E-CID 
capabilities or unilaterally in the absence of step 1, the UE sends an LPP message of type Provide Capabilities to 
the E-SMLC. This message includes the E-CID positioning capabilities of the UE, including the E-CID 
measurements supported as listed in Table 8.3.2-2. If step 1 occurred and the UE cannot fulfill the request, a LPP 
message of type Error is sent instead, providing the specific error reason. 

8.3.3.2 Assistance Data Delivery Procedure 

Editor"s Note: UE-based E-CID is FFS. 



8.3.3.3 



Position Measurement Procedure 



The purpose of this procedure is to enable the E-SMLC to request position measurements from the UE, or to enable the 
UE to provide location measurements to the E-SMLC for position calculation (e.g., in case of basic self location where 
the UE requests its own location). 



8.3.3.3.1 



E-SMLC-initiated Position Measurement 



Figure 8.3.3-3 shows the Position Measurement operations for the E-CID method when the procedure is initiated by the 
E-SMLC. 
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UE 



(1) 
(2) 



E-SMLC 



LPP Mesage(Type: Request Location Information) 



LPP l\/lessage(Type: Provide Location Information) 



Figure 8.3.3-3: E-SMLC-initiated Position IVIeasurement Procedure. 

(1) Optionally, the E-SMLC sends a LPP message of type Request Location Information to the UE for invocation of 
E-CID positioning. This request includes the E-CID measurements requested by the E-SMLC and supported by 
the UE as listed in Table 8.3.2-2 together with a required response time. 

(2) If step 1 occurred, the UE performs the requested measurements. Alternatively, if step 1 did not occur, the UE 
may initiate step 2 and obtain measurements in the absence of a request - e.g. to provide to the E-SMLC in 
association with the procedure in Figure 8.3.3-4. The UE sends an LPP message of type Provide Location 
Information to the E-SMLC before the Response Time provided in step (1) elapsed if step 1 occurred. If step 1 
occurred and the UE is unable to perform the requested measurements, or if the Response Time provided in step 
1 elapsed before any of the requested measurements have been obtained, the UE sends a LPP message of type 
Error instead, providing the error reason. 



8.3.3.3.2 



UE-initiated Position Measurement 



Figure 8.3.3-4 shows the Position Measurement operations for the E-CID method when the procedure is initiated by the 
UE. This procedure may be used by the UE in case of basic self location for UE-assisted mode (i.e., UE requests its 
own location). 



UE 




E-SMLC 


(1) 
(2) 




LPP Message(Type: Request Location Information 
+Type: Provide Location Information) 






LPP Message(Type: Provide Location Information) 













Figure 8.3.3-4: UE-initiated Position IVIeasurement Procedure (Basic Self Location). 

(1) The UE sends a LPP message of type Request Location Information to the E-SMLC, including preferred location 
methods and quality of service parameters (accuracy and response time). The UE may also include an associated 
Provide Location Information message as described in step 2 of Figure 8.3.3-3 containing E-CID measurements 
and possibly other measurements. The Provide Location Information type may include any UE measurements 
already available at the UE and supported by the E-SMLC. 

(2) If the E-SMLC is able to calculate the UE position, it returns the location (possibly together with uncertainty 
information) to the UE in a LPP message of type Provide Location Information. If the E-SMLC cannot obtain 
the UE location, a LPP message of type Error is sent instead, providing the specific error reason. 

8.3.4 Uplink E-CID Positioning Procecdures 

The procedures described in this subclause support E-CID related measurements obtained by the eNodeB and provided 
to the E-SMLC using LPPa. The term 'uplink' is intended to indicate that from the E-SMLC point of view, the involved 
measurements are provided by the eNode B; this set of procedures might also be considered as 'eNB-assisted E-CID'. 
An example of this uplink E-CID positioning method is AoAh-Tadv- 

NOTE: Uplink E-CID positioning does not require LCS support in the UE and therefore, works also with legacy 
UEs (assuming that any involved measurements delivered in RRC are supported by the legacy UEs). 



£75/ 



3GPP TS 36.305 version 9.0.0 Release 9 



43 



ETSI TS 136 305 V9.0.0 (2009-10) 



8.3.4.1 Position Capability Transfer Procedure 

The position capability transfer procedure is not applicable to uplink E-CID positioning. 

8.3.4.2 Assistance Data Delivery Procedure 

The assistance data delivery procedure is not applicable to uplink E-CID positioning. 

8.3.4.3 Position Measurement Procedure 

The purpose of this procedure is to enable the E-SMLC to request position measurements from the eNode B. 
Editor's Note: It is FFS whether an eNode B-initiated position measurement for uplink E-CID is supported. 

8.3.4.3.1 E-SMLC-lnltlated Position Measurement 

Figure 8.3.4-3 shows the Position Measurement operations for the uplink E-CID method when the procedure is initiated 
by the E-SMLC. 



E-SMLC 




eNB 




UE 


(1) 


LF 
(F 


^Pa Message 

vequest Location Information) 


^ 










LPPa Message 
, (Provide Location Information) 
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1 Procedure I 

i_ 1 


(3) 

















Figure 8.3.4-3: E-SMLC-initiated Position IVIeasurement Procedure 

(1) The E-SMLC sends an LPPa message of type Request Location Information to the eNB. This request includes 
indication of E-CID measurements requested and required response time. 

(2) If the E-SMLC in step (1) requested UE measurements (i.e., E-UTRA carrier RSSI, RSRP, RSRQ 
measurements), or if the eNB requires UE measurements associated with the measurements requested by the E- 
SMLC (e.g., Tadv type 1, which requires a UE Tx-Rx time difference measurement to be delivered from the UE 
to the eNB), the eNB may configure the UE to report the measurement information requested as specified in 

[14]. 

(3) The eNode B obtains E-CID measurements as requested in step 1, and then sends an LPPa message of type 
Provide Location Information to the E-SMLC, before the response time provided in step 1 elapsed, and includes 
the obtained E-CID measurements. If the eNode B is unable to perform the requested measurements, or is 
unable to instigate required RRC procedures to obtain the requested measurements from the UE, or the response 
time elapsed before any of the requested measurements were obtained, the eNode B sends an LPPa message of 
type Error instead, providing the error reason. 



8.4 Downlink Supporting Procedures 



Editor"s Note: It is FFS if LPPa is used to transfer assistance data for OTDOA as opposed to relying solely on other 
methods such as OAM. If LPPa is not used for this purpose this section would not be applicable. 
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8.4.1 General 

An E-SMLC is enabled to request downlink location related information from the E-UTRAN in order to support 
downlink positioning. LPPa is employed for this between the E-SMLC and each eNodeB reachable from the E-SMLC 
via any of the MMEs with signalling access to the E-SMLC. 

8.4.2 Location Related Information 

The information that may be transferred from an eNodeB to the E-SMLC to support downlink positioning is listed in 
table 8.4.2-1. 

Table 8.4.2-1 : Information that may be transferred from an eNodeB to the E-SMLC for the Downlink 

Position Method Support 



Information 


UE-assisted 


UE-based 
[FFS] 


Global cell IDs (ECGIs) of eNodeB 


Yes 


Yes 


Physical cell IDs (PCIs) of eNodeB 


Yes 


Yes 


PRS Scheduling 


Yes 


Yes 


If not GNSS synchronized: timing of other neighbor cells 
relative to eNB timing 


Yes 


Yes 


If GNSS synchronized: timing association of eNB cells 
relative to GNSS 


Yes 


Yes 



8.4.3 Location Related Information Acquisition Procedure 

The purpose of this procedure is to enable an E-SMLC to request downlink location related information from an 
eNodeB. 



8.4.3.1 



On Demand Procedure 



Figure 8.4.3-1 shows the location information acquisition operation for the downlink positioning method when 
information is needed on demand in real time. 



eNB 



E-SMLC 



-1 . LPPa Message (Type: Request Location Information)- 
-2. LPPa Message (Type: Provide Location Information)- 



Figure 8.4.3-1: E-SMLC-initiated On Demand Procedure for Location Information Applicable to 

Downlink 

(1) The E-SMLC sends an LPPa message of type Request Location Information to the eNodeB. This request 
includes an indication of the downlink related information requested and a required response time. 

(2) The eNodeB obtains the information requested in step 1 using previously configured or stored information 
and/or real time measurements in the case of a request for timing information where recent timing information is 
not already available. The eNodeB then sends an LPPa message of type Provide Location Information to the E- 
SMLC, before the Response Time provided in step (1) elapsed. If the eNodeB is unable to obtain any of the 
requested information, or if the Response Time elapsed before any of the requested information could be 
obtained, the eNodeB sends an LPPa message of type Error instead, providing the error reason. 



8.4.3.2 



Triggered Procedure 



Figure 8.4.3-2 shows the location information acquisition operation for the downlink positioning method when 
information is needed on a triggered basis. 
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eNB 



E-SMLC 



-1 . LPPa Message (Type: Request Location Information)- 
-2. LPPa Message (Type: Provide Location Information)- 



-3. LPPa Message (Type: Provide Location Infornnation)- 



-4. LPPa Message (Type: Provide Location Information)- 



Figure 8.4.3-2: E-SMLC-initiated Triggered Procedure for Location Information Applicable to 

Downlink 

(1) Optionally, the E-SMLC sends an LPPa message of type Request Location Information to the eNodeB. This 
request includes an indication of the downlink related information requested, triggering criteria for responses 
(e.g. periodic time interval and/or threshold change in a reported information item), a response time and criteria 
for terminating responses (e.g. a limit on the number of responses or a maximum reporting period). 

(2) Either in response to step 1 or based on configuration information, the eNodeB obtains the information requested 
in step 1 or defined by configuration using already available information and/or real time measurements. The 
eNodeB then sends an LPPa message of type Provide Location Information to the E-SMLC carrying this 
information, before the Response Time provided in step (1) elapsed if step 1 occurs. If the eNodeB is unable to 
obtain any of the requested information, or if the Response Time elapsed before any of the requested information 
could be obtained, the eNodeB sends an LPPa message of type Provide Location Information to the E-SMLC 
containing a cause indication and no location related information. 

(3) When the trigger criteria provided in step 1 or by configuration indicate the need for a new response (e.g. a 
periodic timer has expired or some timing difference has changed by more than a specified amount), the eNodeB 
obtains the latest information requested either in step 1 or by configuration. The eNodeB then sends a further 
LPPa message of type Provide Location Information to the E-SMLC containing this information, before the 
Response Time provided in step (1) or by configuration elapses following occurrence of the trigger. If the 
eNodeB is unable to obtain any of the requested information, or if the Response Time elapsed before any of the 
requested information could be obtained, the eNodeB sends an LPPa message of type Provide Location 
Information to the E-SMLC containing a cause indication and no location related information. 

(4) Step 3 is repeated for each further occurrence of the trigger(s) provided either in step 1 or by configuration until 
the criteria provided in step 1 or by configuration occur for cessation of reporting. This may or may not occur in 
conjunction with a reporting criterion. Regardless of which is the case, the eNodeB behaves as in step 3 to send a 
further LPPa message of type Provide Location Information to the E-SMLC. This message also carries an end of 
procedure indication. 
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Annex A (informative): 
Definitions and Terms 



[FFS; intended for definitions and terminology more extensive than the acronym definitions.] 
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Annex B (informative): Use of LPP with SUPL 

The design goal of LPP is to enable it to be used in user plane location solutions such as OMA SUPL ([17], [18]) and 
this informative annex shows how LPP can be used in SUPL 2.0. 



B.1 SUPL 2.0 Positioning IVIethods and Positioning 
Protocols 

The following table shows how the 3GPP positioning protocols are supported in SUPL 2.0. 

Table B.1 : SUPL support of positioning methods 



Positioning Protocol: 


RRLP 

(GSM/GPRS/WCDMA/ 

LTE/WLAN/WiMAX) 


RRC 
(WCDMA) 


LPP 
(LTE) 


Positioning Method: 


A-GPS (A-GANSS) SET Assisted 


■/ 


^ 


^ 


A-GPS (A-GANSS) SET Based 


• 


^ 


• 


Autonomous GPS/GANSS 


•/ 


•/ 


•/ 


Enhanced Cell ID 


V 


■/ 


/ 


Enhanced Observed Time Difference 
(E-OTD) 


•y (GSM only) 


NA 


NA 


Observed Time Difference of Arrival 
(OTDOA) 


NA 


^ 


^ 



Note: What is referred to in the SUPL specifications as 'Enhanced Cell ID is a UE- Assisted positioning mode 
where the neighbouring cell measurements are carried at the SUPL layer (in the SUPL_POS_INIT for 
example). For LTE, the ASN.l container for this mode is defined as follows: 



LteCelllnformation : 


:= SEQUENCE { 












refMCC 


INTEGER (0. 


.999) , -- Mobile 


Country Code 










refMNC 


INTEGER (0 . 


.999) , -- Mobile 


Network Code 










refCI 


BIT STRING(SIZE (29)), -- ] 


[jTE Cell-Id including the 


CSG 


bit 




tA 


INTEGER (0. 


.255) OPTIONAL, 


-- Timing Advance 


as per 


3GPP 


TS 3 6 


.321 


measRes 


,ultListEUTRA MeasResultLi 


3tEUTRA OPTIONAL, 










MeasResultListEUTRA 


::= SEQUENCE (SIZE (1 . .maxCellReport ) ) OF 


SEQUENCE 


{ 


physicalCellldenti 


ty INTEGER (0. .504) , 










globalCell Identity 


BIT STRING(SIZE (29)) OPTIONAL, -- 


inc 


Ludes 


the 


CSG bit 
















earf cn- 


DL INTEGER (0.. 32767), 


-- as per 3GPP TS 


36 .331 








measRes 


,ultEUTRA SEQUENCE { 












rsrpResult INTEGER 


(0. .97) OPTIONAL 


--as per 3GPP 


TS 36.331 






rsrqResult INTEGER 
•■•} 
} 


(0 . .33) OPTIONAL 


--as per 3GPP 


TS 36.331 







The IE "MeasResultListEUTRA" mirrors the equivalent IE from the RRC specification: 
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MeasResultEUTRA : : = SEQUENCE { 






physCellld 


PhysCellld, 




cgi-Info 


SEQUENCE { 




cellGloballd 


CellGloballdEUTRA, 




trackingAreaCode 


TrackingAreaCode , 




plmn-IdentityList 


PLMN-IdentityList2 


OPTIONAL 


} 


OPTIONAL, 




measResult 


SEQUENCE { 




rsrpResult 


RSRP- Range 


OPTIONAL, 


rsrqResult 

} 
} 


RSRQ-Range 


OPTIONAL, 



It should be noted that in addition to the container provided by SUPL itself, any E-CID positioning methods defined 
within LPP proper can be supported in SUPL, via tunneling LPP as shown in this annex (in the same manner that A- 
GNSS and OTDOA are supported). 



B.2 SUPL 2.0 and LTE Architecure 

This section describes interworking between the control-plane LCS architecture, as defined in the main body of this 
specification, and SUPL 2.0. The E-SMLC either includes or has an interface to an SPC function as defined in OMA 
SUPL V2.0 ([17], [18]). It can thus provide a consistent set of positioning methods for deployments utilizing both 
control-plane and user -plane. 

The interworking does not enable use of user-plane signalling for part of a control-plane positioning session. The user 
plane in the interworking here is not intended as an alternative path for control-plane signalling that would be needed 
between UE and eNodeB for mechanisms such as A-GPS in a standalone C-plane solution. 

This interworking does enable the SPC to retrieve measurements (e.g., GNSS-to-RAN time relations) from eNodeB. 

The underlying architecture is shown in Figur B.l. Note that, for interworking between user-plane and control-plane 
positioning, no new interfaces need to be defined as compared to those in the figure, assuming the SPC is either 
integrated in the E-SMLC or attached to it with a proprietary interface. 
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Figure B.1 : System architecture underlying positioning 

The Lup and Lip interfaces shown in this architecture are part of the user-plane solution only and are not required for 
control-plane positioning. The SLs interface is required for both control-plane and user -plane positioning, and needs to 
be capable of querying eNode Bs for information not related to a UE connection. 
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SUPL, including the use of LPP over SUPL, takes place as part of the general user-plane protocol stack shown in Figure 
B.2. SUPL occupies the application layer in the stack, with LPP (or another positioning protocol) transported as another 
layer above SUPL. 
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IP 



PDCP 
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Figure B.2: User-plane protocol stack 



B.3 LPP session procedures using SUPL 

This section indicates how an LPP session relates to the SUPL structure. Figure B.3 shows how SUPL and LPP can be 
combined within a SUPL positioning session. Step 4 here is repeated to exchange multiple LPP messages between the 
SLP and SET. 



SLR 



SET 



1.SUPLINIT 



2 Establish secure TCP/IP Connection 



3. SUPL POS INIT (E-CID measurements) 



4. SUPL POS (LPP PDU) 



5. SUPL END 



Figure B.3: LPP session over SUPL 

For positioning operations which take place entirely within an LPP session (step 4 in Figure x.3), the flow of LPP 
messages can be the same as in the control-plane version of LPP; the role of the (LPP) target is taken by the target SET, 
and that of the (LPP) server by the SLP. An example LPP flow, including exchange of capabilities, request and delivery 
of assistance data, and request and delivery of positioning information, is shown in Figure B.4. 
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LPP Target 
(Target SET) 



LPP Server 
(SLP) 



— 1. LPP PDU: Location information request [position estimate, transaction A]-^ 

< 2. LPP PDU: Capability request [transaction B] 

3. LPP PDU: Capability indication [transaction B] ► 



4. LPP PDU: Assistance data request [transaction C]- 
-5. LPP PDU: Assistance data delivery [transaction C]- 



-6. LPP PDU: Location information request [measurements, transaction D] 

7. LPP PDU: Location information [measurements, transaction D] ► 



-8. LPP PDU: Location information [position estimate, transaction A]- 



Figure B.4: LPP session over SUPL 



B.4 Procedures combining C-plane and U-plane 
operations 

Since SUPL is by definition carried over the user plane, it is not really applicable to operations terminating at the eNode 
B. Thus, in some cases where information from the eNode B and UE needs to be merged for a positioning operation, 
SUPL operations must take place in combination with control-plane procedures over LPPa. 

This situation could arise in the case of UE-assisted OTDOA, for example, in which the SLP needs to provide the UE 
(in a SUPL session) with assistance data supplied by various eNode Bs. This section uses a UE-assisted OTDOA 
positioning operation as a running example. 

Although the positioning server in this operation is of course the SLP, the existence of the Lip interface means that the 
SLP can communicate freely with the E-SMLC via the SPC. In particular, this means that assistance data that were 
delivered to the E-SMLC via LPPa can be transferred over to the SLP for delivery to the UE via LPP over SUPL. 

Several ways to realise this general behaviour are possible. In the simplest case, the E-SMLC could be supplied with 
the necessary assistance data in advance, so that they can be supplied to the SLP without any actual LPPa procedures 
taking place in real time (and possibly even before the positioning transaction begins). 
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UE (SET) 



eNode B 



E-SMLC 



Assistance data_ 
(via LPPa) 



SLP 



SUPL session establishment 



Assistance data_ 
(via LPP/SUPL) 



Assistance data (via Lip) 



Figure B.5: Transfer of OTDOA assistance data to UE via SUPL 

In the event that the E-SMLC does not have the required assistance data available, however, it would need to retrieve 
them from appropriate eNode Bs once it was made aware that they were needed. 



eNode B 




E-SMLC 



SLP 



SUPL session establishment 



Assistance data request_ 
via LPP/SUPL) 



Assistance data request_ 
(via LPPa) 



Assistance data_ 
(via LPPa) 



Assistance data request_ 
(via Lip) 



Assistance data_ 
(via Lip) 



Assistance data_ 
via LPP/SUPL)" 



Figure B.6: Transfer to the UE via SUPL of OTDOA assistance data not already available at the E- 

SMLC 

In both cases, it should be noted that the retrieval of the assistance data is transparent to the UE and to the actual SUPL 
session. This model is parallel to the approach used with A-GNSS, in which assistance data such as satellite 
ephemerides are retrieved from sources entirely external to the cellular network. For purposes of LP? over SUPL, the 
delivery of assistance data to the SLP can be looked on as an independent external process. 

The delivery of assistance data to the UE, however, takes place through the same mechanisms as control-plane LPP, 
transported through SUPL. 
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